\chapter{Critique}


L'article remplit ses objectifs :

D'une part, il identifie les difficultés à tirer partie d'une architecture hiérarchisée.
En effet, optimiser l'utilisation des coeurs des processeurs multicoeurs est une problématique primordiale dans la tendance actuelle qui est à la multiplication du nombre de coeurs.

D'autre part, il met l'accent sur la criticité de la prise de mesure et le risque de perturber le fonctionnement du prgramme et donc ses performances. 
Il met en place des recommandations pour effectuer ces mesures dans les meilleurs conditions possibles.

Enfin, il propose une méthode d'optimisation simple à mettre en place, qui pourrait être automatisée par un compilateur et qui permet non seulement d'obtenir une amélioration globale des performances, mais aussi une optimisation de la scalabilité \textit{intranode}.

On pourrait cependant faire les remarques suivantes :
\begin{itemize}
	\item Un seul benchmark a été utilisé. Même s'il s'agit d'une référence en matière d'application HPC, il serait tout de même intéressant d'en tester d'autres.
	\item Les auteurs ne précisent pas la manière dont MPI est utilisé : s'agit-il toujours de recopies de données ? ou alors y a t-il des partages entre les coeurs d'un multiprocesseur ?
	\item Au niveau d'un (multiprocesseur) noeud, n'aurait-il pas été intéressant d'utiliser OpenMP pour éviter les envois de messages (MPI) ntre les coeurs d'un multiprocesseur.
	\item La structure de l'article n'est pas très claire : il faut parfois aller chercher des informations plus loin ou plus haut dans l'article pour comprendre le paragraphe en cours. Certains graphiques présentent des données non explicitées, par exemple la figure 7 page 8, illustre le core skew pour un algo de base, une version optimisée 1 et une version optimisée 2. On ne sait pas de quelles optimisations il s'agit. D'autres sont expliqués textuellement mais n'apparaissent pas dans l'article.
	\item Il y a également quelques coquilles qui nuisent à la compréhension, par exemple pour la microfission, l'article annonce 4 tableaux et 24 séquences d'accès, alors que dans le code de la figure 8, il n'y en n'a respectivement que 3 et 20.
	\item Certains concepts sont peu définis : les notions de scalabilité \textit{intranode/internode/interchip/intrachip} auraient peut-être mérité un visuel.
	\item L'explication de l'expérimentation manque parfois de détails : par exemple, lorsque le nombre de coeurs est augmenté de 1 à 16 pour l'étude de la scalabilité intranode, on ne sait pas s'ils sont uniformément répartis ou s'ils sont prioritairement sur un même coeur. On ne sait donc pas précisément, quelles communications sont observées : \textit{intrachip} ou \textit{interchip}.
	\item Dans la classification des outils de profilage, des outils tels que PAPI et PerfCtr sont recommandés, mais les critères de choix de ces outils ne sont pas explicités. 
\end{itemize}

Dans l'ensemble, c'est un article très intéressant, mais difficile à comprendre parfois à cause d'un manque de structure.
